home *** CD-ROM | disk | FTP | other *** search
/ Aminet 2 / Aminet AMIGA CDROM (1994)(Walnut Creek)[Feb 1994][W.O. 44790-1].iso / Aminet / dev / amos / AMOSList0993.lzh / AMOSLIST / 000210_amos-request@svcs1.digex.net_Mon Sep 20 11:47:52 1993.msg < prev    next >
Internet Message Format  |  1993-10-03  |  2KB
  1. Received: from nextsun.INS.CWRU.Edu by access.digex.net with SMTP id AA18255
  2.   (5.65c/IDA-1.4.4 for <mcox@access.digex.com>); Mon, 20 Sep 1993 11:47:50 -0400
  3. Received: from svcs1.digex.net by nextsun.INS.CWRU.Edu with SMTP (5.65b+ida+/CWRU-1.5.2-freenet-gw)
  4.     id AA18277; Mon, 20 Sep 93 11:46:47 -0400 (from amos-request@svcs1.digex.net for mcox@access.digex.com)
  5. Received: by svcs1.digex.net id AA06814
  6.   (5.65c/IDA-1.4.4 for amos-list-out); Mon, 20 Sep 1993 11:29:35 -0400
  7. Received: from access.digex.net by svcs1.digex.net with SMTP id AA06810
  8.   (5.65c/IDA-1.4.4 for <amos-list@svcs1.digex.net>); Mon, 20 Sep 1993 11:29:34 -0400
  9. Received: from vax.mbhs.edu by access.digex.net with SMTP id AA15268
  10.   (5.65c/IDA-1.4.4 for <amos-list@access.digex.net>); Mon, 20 Sep 1993 11:29:30 -0400
  11. Message-Id: <199309201529.AA15268@access.digex.net>
  12. Date: 20 Sep 93 11:32:00 EST
  13. From: "Andrew Church" <95ACHURCH@vax.mbhs.edu>
  14. Subject: Re: Pro Compiler Oddity
  15. To: "amos-list" <amos-list@access.digex.net>
  16. Status: RO
  17.  
  18. >I got the Pro compiler the other day, despite my misgivings of getting the
  19. >first version of anything, and have been pleasantly surprised by the way 
  20. >it, well, works the way its supposed to.  It compiled all my programs
  21. >correctly with one exception:  It changed the length of two of my music
  22. >banks by +2.  This would not ordinarily be a problem except that I tell
  23. >which piece of music is in which bank using lengths and swap in and out of
  24. >bank three as needed.
  25. >
  26. >It seems strange that only two of the five music banks in the program are
  27. >changed.  And it only happens with the stand alone option.  When I compile
  28. >to AMOS it works just fine.  I worked around it without any problem (just
  29. >started comparing approximate lengths rather that actual values) but I
  30. >thought I'd report it in case anyone was keeping an actual error list.
  31.  
  32.   In an executable file, all "hunks" (file sections) need to have a size that
  33. is a multiple of 4.  If the two banks that got a size adjustment were not
  34. multiples of 4 (the size, not the bank number), that would be why.  (Although
  35. why the compiler would store each bank in a separate hunk is beyond me; it
  36. would make more sense to just put them all in the same hunk.)
  37.  
  38.   --Andy Church
  39.